This rule is deprecated, and will eventually be removed.
Deserializing objects is security-sensitive. For example, it has led in the past to the following vulnerabilities:
Object deserialization from an untrusted source can lead to unexpected code execution. Deserialization takes a stream of bits and turns it into an
object. If the stream contains the type of object you expect, all is well. But if you’re deserializing data coming from untrusted input, and an
attacker has inserted some other type of object, you’re in trouble. Why? A known attack
scenario involves the creation of a serialized PHP object with crafted attributes which will modify your application’s behavior. This attack
relies on PHP magic methods like __desctruct, __wakeup or
__string. The attacker doesn’t necessarily need the source code of the targeted application to exploit the vulnerability, he can also
rely on the presence of open-source component and use tools to craft malicious payloads.
Ask Yourself Whether
- an attacker could have tampered with the source provided to the deserialization function
- you are using an unsafe deserialization function
You are at risk if you answered yes to any of those questions.
Recommended Secure Coding Practices
To prevent insecure deserialization, it is recommended to:
- Use safe libraries that do not allow code execution at deserialization.
- Not communicate with the outside world using serialized objects
- Limit access to the serialized source
- if it is a file, restrict the access to it.
- if it comes from the network, restrict who has access to the process, such as with a Firewall or by authenticating the sender first.
See
